Methods and apparatus for multi-view video coding

ABSTRACT

There are provided methods and apparatus for multi-view video coding. A video encoder includes an encoder for encoding a block in a picture by choosing between temporal prediction and cross-view prediction to enable a prediction for the block. The picture is one of a set of pictures corresponding to multi-view video content and having different view points with respects to a same or similar scene. The picture represents one of the different view points. A high-level syntax is used to indicate the use of cross-view prediction for the block.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application Ser.No. 60/757,289, entitled “Multi-View Video Coding System”, filed 9 Jan.2006, which is incorporated by reference herein. Moreover, thisapplication is related to the non-provisional application, AttorneyDocket No. PU060004, entitled “Methods and Apparatus for Multi-ViewVideo Coding”, which is commonly assigned, incorporated by reference inits entirety, and concurrently filed herewith.

FIELD OF THE INVENTION

The present invention relates generally to video encoders and decodersand, more particularly, to methods and apparatus for Multi-view VideoCoding.

BACKGROUND OF THE INVENTION

Multi-view video coding (MVC) is the compression framework for theencoding of multi-view sequences. A Multi-view Video Coding (MVC)sequence is a set of two or more video sequences that capture the samescene from a different view point.

It has been widely recognized that Multi-view Video Coding is a keytechnology that serves a wide variety of applications, includingfree-viewpoint and 3D video applications, home entertainment andsurveillance. In those multi-view applications, the amount of video datainvolved is enormous. Thus, there exists the need for efficientcompression technologies to improve the coding efficiency of currentvideo coding solutions performing simulcast of independent views.

In recent years, much effort has been put in the design of efficientmethods for compressing stereoscopic video. Conventional monoscopiccompression methods can be applied independently to the left and rightviews of a stereo image pair. However, higher compression ratios can beachieved if the high correlation between views is exploited.

Regarding a prior art approach in which both views of a stereoscopicimage pair are encoded, a Multi-View Profile (MVP) was defined in theInternational Organization for Standardization/InternationalElectrotechnical Commission (ISO/IEC) Moving Picture Experts Group-2(MPEG-2) standard to transmit a pair of video signals. MVP relies on amulti-layer signal representation approach such that one view (often theleft view) is assigned to a base layer, and the other view is assignedto an enhancement layer. Monoscopic coding with the same tools as MainProfile (MP) is applied to the base layer. The enhancement layer iscoded using temporal scalability tools and a hybrid prediction of motionand disparity fields.

In prior art methods relating to the International Organization forStandardization/International Electrotechnical Commission (ISO/IEC)Moving Picture Experts Group-4 (MPEG-4) Part 10 Advanced Video Coding(AVC) standard/International Telecommunication Union, TelecommunicationSector (ITU-T) H.264 recommendation (hereinafter the “MPEG-4 AVCstandard”), stereoscopic video coding can be performed in two differentways: (i) as a particular case of interlaced image coding, where all thefields of a particular parity are assigned to the left view and all thefields of the opposite parity are considered the right view of thestereo-view content; or alternatively (ii) by alternating frames fromthe left and rights views to create a single monoscopic video sequence.A stereovision supplemental enhancement information (SEI) messageprovides an indication to the decoder of whether or not the coded videosequence represents stereoscopic content and which method was used toencode the corresponding content.

These previously known methods require minimum modifications of existingmonoscopic coding techniques. However, they show a limited ability forreducing the redundancy existing between the two views in a stereoscopicpair. As a result, the encoding of stereo-view results in a largeoverhead when compared to the encoding of a single monoscopic view.Furthermore, there is no previous support for encoding of more than twocamera views.

SUMMARY OF THE INVENTION

These and other drawbacks and disadvantages of the prior art areaddressed by the present invention, which is directed to methods andapparatus for Multi-view Video Coding.

According to an aspect of the present invention, there is provided avideo encoder. The video encoder includes an encoder for encoding ablock in a picture using at least one of two cross-view referencepicture lists. The picture is one of a set of pictures corresponding tomulti-view video content and having different view points with respectto a same or similar scene. The picture represents a current one of thedifferent view points. The two cross-view reference picture listscorrespond to reference pictures having ones of the different viewspoints other than the current one.

According to another aspect of the present invention, there is provideda video encoder. The video encoder includes at least one buffer forstoring decoded pictures corresponding to multi-view content fordifferent view points of a same or similar scene.

According to yet another aspect of the present invention, there isprovided a video encoding method. The method includes encoding a blockin a picture using at least one of two cross-view reference picturelists. The picture is one of a set of pictures corresponding tomulti-view video content and having different view points with respectto a same or similar scene. The picture represents a current one of thedifferent view points. The two cross-view reference picture listscorrespond to reference pictures having ones of the different viewspoints other than the current one.

According to still another aspect of the present invention, there isprovided a video encoding method. The method includes storing, in atleast one buffer, decoded pictures corresponding to multi-view contentfor different view points of a same or similar scene.

According to a further aspect of the present invention, there isprovided a video decoder. The video decoder includes a decoder fordecoding a block in a picture using at least one of two cross-viewreference picture lists. The picture is one of a set of picturescorresponding to multi-view video content and having different viewpoints with respect to a same or similar scene. The picture represents acurrent one of the different view points. The two cross-view referencepicture lists correspond to reference pictures having ones of thedifferent views points other than the current one.

According to a still further aspect of the present invention, there isprovided a video decoder. The video decoder includes at least one bufferfor storing decoded pictures corresponding to multi-view content fordifferent view points of a same or similar scene.

According to an additional aspect of the present invention, there isprovided a video decoding method. The method includes decoding a blockin a picture using at least one of two cross-view reference picturelists. The picture is one of a set of pictures corresponding tomulti-view video content and having different view points with respectto a same or similar scene. The picture represents a current one of thedifferent view points. The two cross-view reference picture listscorrespond to reference pictures having ones of the different viewspoints other, than the current one.

According to a still additional aspect of the present invention, thereis provided a video decoding method. The method includes storing, in atleast one buffer, decoded pictures corresponding to multi-view contentfor different view points of a same or similar scene.

These and other aspects, features and advantages of the presentinvention will become apparent from the following detailed descriptionof exemplary embodiments, which is to be read in connection with theaccompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may be better understood in accordance with thefollowing exemplary figures, in which:

FIG. 1 is a block diagram for an exemplary Multi-view Video Coding (MVC)encoder to which the present principles may be applied, in accordancewith an embodiment of the present principles;

FIG. 2 is a block diagram for an exemplary Multi-view Video Coding (MVC)decoder to which the present principles may be applied, in accordancewith an embodiment of the present principles;

FIG. 3 is a flow diagram for an exemplary method for reference listconstruction for multi-view video content in accordance with anembodiment of the present principles;

FIG. 4 is a flow diagram for an exemplary method for performing atemporal/cross view mode decision in accordance with an embodiment ofthe present principles;

FIG. 5 is a flow diagram for an exemplary method for processing motionand disparity vectors for the same slice corresponding to multi-viewvideo content in accordance with an embodiment of the presentprinciples; and

FIG. 6 is a flow diagram for another method for processing motion anddisparity vectors for multi-view video content in accordance with anembodiment of the present principles.

DETAILED DESCRIPTION

The present invention is directed to methods and apparatus forMulti-view Video Coding.

The present description illustrates the principles of the presentinvention. It will thus be appreciated that those skilled in the artwill be able to devise various arrangements that, although notexplicitly described or shown herein, embody the principles of theinvention and are included within its spirit and scope.

All examples and conditional language recited herein are intended forpedagogical purposes to aid the reader in understanding the principlesof the invention and the concepts contributed by the inventor tofurthering the art, and are to be construed as being without limitationto such specifically recited examples and conditions.

Moreover, all statements herein reciting principles, aspects, andembodiments of the invention, as well as specific examples thereof, areintended to encompass both structural and functional equivalentsthereof. Additionally, it is intended that such equivalents include bothcurrently known equivalents as well as equivalents developed in thefuture, i.e., any elements developed that perform the same function,regardless of structure.

Thus, for example, it will be appreciated by those skilled in the artthat the block diagrams presented herein represent conceptual views ofillustrative circuitry embodying the principles of the invention.Similarly, it will be appreciated that any flow charts, flow diagrams,state transition diagrams, pseudocode, and the like represent variousprocesses which may be substantially represented in computer readablemedia and so executed by a computer or processor, whether or not suchcomputer or processor is explicitly shown.

The functions of the various elements shown in the figures may beprovided through the use of dedicated hardware as well as hardwarecapable of executing software in association with appropriate software.When provided by a processor, the functions may be provided by a singlededicated processor, by a single shared processor, or by a plurality ofindividual processors, some of which may be shared. Moreover, explicituse of the term “processor” or “controller” should not be construed torefer exclusively to hardware capable of executing software, and mayimplicitly include, without limitation, digital signal processor (“DSP”)hardware, read-only memory (“ROM”) for storing software, random accessmemory (“RAM”), and non-volatile storage.

Other hardware, conventional and/or custom, may also be included.Similarly, any switches shown in the figures are conceptual only. Theirfunction may be carried out through the operation of program logic,through dedicated logic, through the interaction of program control anddedicated logic, or even manually, the particular technique beingselectable by the implementer as more specifically understood from thecontext.

In the claims hereof, any element expressed as a means for performing aspecified function is intended to encompass any way of performing thatfunction including, for example, a) a combination of circuit elementsthat performs that function or b) software in any form, including,therefore, firmware, microcode or the like, combined with appropriatecircuitry for executing that software to perform the function. Theinvention as defined by such claims resides in the fact that thefunctionalities provided by the various recited means are combined andbrought together in the manner which the claims call for. It is thusregarded that any means that can provide those functionalities areequivalent to those shown herein.

Reference in the specification to “one embodiment” or “an embodiment” ofthe present principles means that a particular feature, structure,characteristic, and so forth described in connection with the embodimentis included in at least one embodiment of the present principles. Thus,the appearances of the phrase “in one embodiment” or “in an embodiment”appearing in various places throughout the specification are notnecessarily all referring to the same embodiment.

Turning to FIG. 1, an exemplary Multi-view Video Coding (MVC) encoder isindicated generally by the reference numeral 100. The encoder 100includes a combiner 105 having an output connected in signalcommunication with an input of a transformer 110. An output of thetransformer 110 is connected in signal communication with an input ofquantizer 115. An output of the quantizer 115 is connected in signalcommunication with an input of an entropy coder 120 and an input of aninverse quantizer 125. An output of the inverse quantizer 125 isconnected in signal communication with an input of an inversetransformer 130. An output of the inverse transformer 130 is connectedin signal communication with a first non-inverting input of a combiner135. An output of the combiner 135 is connected in signal communicationwith an input of an intra predictor 145 and an input of a deblockingfilter 150. An output of the deblocking filter 150 is connected insignal communication with an input of a reference picture store 155 (forview i). An output of the reference picture store 155 is connected insignal communication with a first input of a motion compensator 175 anda first input of a motion estimator 180. An output of the motionestimator 180 is connected in signal communication with a second inputof the motion compensator 175

An output of a reference picture store 160 (for other views) isconnected in signal communication with a first input of adisparity/illumination estimator 170 and a first input of adisparity/illumination compensator 165. An output of thedisparity/illumination estimator 170 is connected in signalcommunication with a second input of the disparity/illuminationcompensator 165.

An output of the entropy decoder 120 is available as an output of theencoder 100. A non-inverting input of the combiner 105 is available asan input of the encoder 100, and is connected in signal communicationwith a second input of the disparity/illumination estimator 170, and asecond input of the motion estimator 180. An output of a switch 185 isconnected in signal communication with a second non-inverting input ofthe combiner 135 and with an inverting input of the combiner 105. Theswitch 185 includes a first input connected in signal communication withan output of the motion compensator 175, a second input connected insignal communication with an output of the disparity/illuminationcompensator. 165, and a third input connected in signal communicationwith an output of the intra predictor 145.

A mode decision module 140 has an output connected to the switch 185 forcontrolling which input is selected by the switch 185.

Turning to FIG. 2, an exemplary Multi-view Video Coding (MVC) decoder isindicated generally by the reference numeral 200. The decoder 200includes an entropy decoder 205 having an output connected in signalcommunication with an input of an inverse quantizer 210. An output ofthe inverse quantizer is connected in signal communication with an inputof an inverse transformer 215. An output of the inverse transformer 215is connected in signal communication with a first non-inverting input ofa combiner 220. An output of the combiner 220 is connected in signalcommunication with an input of a deblocking filter 225 and an input ofan intra predictor 230. An output of the deblocking filter 225 isconnected in signal communication with an input of a reference picturestore 240 (for view i). An output of the reference picture store 240 isconnected in signal communication with a first input of a motioncompensator 235.

An output of a reference picture store 245 (for other views) isconnected in signal communication with a first input of adisparity/illumination compensator 250.

An input of the entropy coder 205 is available as an input to thedecoder 200, for receiving a residue bitstream. Moreover, an input of amode module 260 is also available as an input to the decoder 200, forreceiving control syntax to control which input is selected by theswitch 255. Further, a second input of the motion compensator 235 isavailable as an input of the decoder 200, for receiving motion vectors.Also, a second input of the disparity/illumination compensator 250 isavailable as an input to the decoder 200, for receiving disparityvectors and illumination compensation syntax.

An output of a switch 255 is connected in signal communication with asecond non-inverting input of the combiner 220. A first input of theswitch 255 is connected in signal communication with an output of thedisparity/illumination compensator 250. A second input of the switch 255is connected in signal communication with an output of the motioncompensator 235. A third input of the switch 255 is connected in signalcommunication with an output of the intra predictor 230. An output ofthe mode module 260 is connected in signal communication with the switch255 for controlling which input is selected by the switch 255. An outputof the deblocking filter 225 is available as an output of the decoder.

Multi-view video coding (MVC) is the compression framework for theencoding of multi-view sequences. A Multi-view Video Coding (MVC)sequence is a set of two or more video sequences that capture the samescene from a different view point.

Since a multi-view video source includes multiple views of the samescene, there exists a high degree of correlation between the multipleview images. Therefore, view redundancy can be exploited in addition totemporal redundancy and is achieved by performing view prediction acrossthe different views. Accordingly, embodiments of the present principlesdescribed herein may involve both temporal and cross-view prediction.

For illustrative purposes, embodiments of the present principles aredescribed herein with respect to the MPEG-4 AVC standard. However, it isbe appreciated that the present invention is not limited to the MPEG-4AVC standard and, given the teachings of the present principles providedherein, one of ordinary skill in this and related arts will contemplatethis and other video coding standards capable of Multi-view Video Codingto which the present principles may be applied, while maintaining thescope of the present principles. Embodiments of the present principlesdescribed herein relating to the MPEG-4 AVC standard may involve, e.g.,deblocking filter changes and/or entropy coding of syntaxes.

In an embodiment, at the slice level, cross-view prediction lists areintroduced to enable disparity prediction, and a cross-view coding typesyntax is added to indicate the coding type of disparity prediction. Atthe macroblock (MB) level, a flag syntax is introduced to indicatewhether motion compensation or disparity compensation is used for eachsignal block. Moreover, other changes that may utilized in embodimentsdirected to the MPEG-4 AVC standard include, e.g., a deblocking filter,Context Adaptive Binary Arithmetic Coding (CABAC) contexts for the newsyntaxes, and additional syntaxes in the parameter set level and sliceheader level.

A description will now be given regarding cross-view coding type andcross-view reference lists in accordance with an embodiment of thepresent principles.

The MPEG-4 AVC standard performs inter-frame prediction by forming twoprediction lists, List0 and List1. Hence, an image block in the currentframe can be compensated either by using only one reference picture inthe List0, or by using two references pictures, one from each list. Inthe slice header, a slice_type syntax is signaled to indicate thetemporal coding type for each slice. When slice_type=P_SLICE, only List0will be used in motion compensation. When slice_type=B_SLICE, both List0and List1 can possibly be used in motion compensation.

To enable cross-view prediction among different views, an embodiment ofthe present principles involves using two new prediction lists:ViewList0 and ViewList1. Pictures in ViewList0/ViewList1 are referencepictures from camera views other than the current view. A new syntaxview_slice_type in the slice header is used to indicate the coding typefor the cross-view prediction. For example, if a specific slice hasslice_type=B_SLICE and view_slice_type=P_SLICE, then a macroblock (MB)in that slice can be either temporally coded as a B_SLICE coding type,or cross-view coded as a P_SLICE coding type.

An alternative way of enabling cross-view predictions in the MPEG-4 AVCstandard frame work involves inserting reference pictures from otherview in the lists List0/List1 without introducing new view predictionlists and cross-view coding type. However, the advantages of the firstapproach are as follows. One advantage of the first approach is thatsince reference pictures in ViewList0/ViewList1 only include cross-viewreferences, signaling the ref_idx will spend less bits than having bothsame-view references and cross-view references in the same list. Anotheradvantage of the first approach is that having two new listsViewList0/ViewList1 provides a separate way of handing temporal andcross-view predictions. This relates to the case where the List0/List1include both temporal references and cross-view references, so that theMPEG-4 AVC standard reordering process for reference picture listsconstruction will need to be modified and will necessarily be morecomplex.

In an embodiment, cross-view reference lists for each slice may beformed according to the following rules. With respect to a first rule,in the slice header, the number of cross-view reference pictures andtheir view_id's are signaled for both ViewList0 and ViewList1. Theview_id's are distinctive in each of the two cross-view predictionlists. With respect to a second rule, reference pictures in thecross-view prediction list are ordered in the same sequence as theyappear in the slice header. For each referred view, the referencepicture with the closest Picture Order Count (POC) number (with respectto the POC of current slice) is used in current slice's cross-viewprediction list.

Additional reference reordering syntaxes can be included to allow moreflexible handling of cross-view reference pictures.

Turning to FIG. 3, an exemplary method for reference list constructionfor multi-view video content is indicated generally by the referencenumeral 300. The method 300 includes a start block 305 that passescontrol to a decision block 310. The decision block 310 determineswhether or not a current slice type is P slice or B slice. If so, thencontrol is passed to a function block 315. Otherwise, control is passedto a decision block 330.

The function block 315 constructs List0 using temporal references; andpasses control to a decision block 320. The decision block 320determines whether or not the current slice type is B slice. If so, thencontrol is passed to function block 325. Otherwise, control is passed tothe decision block 330.

The function block 325 constructs List1 using temporal references, andpasses control to the decision block 330.

The decision block 330 determines whether or not the current view slicetype is P slice or B slice. If so, then control is passed to a functionblock 335. Otherwise, control is passed to a loop limit block 350.

The function block 335 constructs ViewList0 using cross-view references,and passes control to a decision block 340. The decision block 340determines whether or not the current view slice type is B slice. If so,then control is passed to a function block 345. Otherwise, control ispassed to the loop limit block 350.

The function block 345 constructs ViewList0 using cross-view references,and passes control to the loop limit block 350.

The loop limit block 350 begins a loop over each macroblock includingsetting a range for the loop using a variable mb=0 toMacroBlocksInPic−1, and passes control to a function block 355. Thefunction block 355 encodes a current macroblock using List0/List1, andpasses control to a decision block 360. The decision block 360determines whether or not the current view slice type is equal P sliceor B slice. If so, the control is passed to a function block 365.Otherwise, control is passed to a function block 370.

The function block 365 encodes the current macroblock usingViewList0/ViewList1, and passes control to the function block 370.

The function block 370 selects the best mode, sets themvc_prediction_flag, and passes control to a function block 375. Thefunction block 375 performs motion/disparity vector buffer processing,and passes control to a loop limit block 380. The loop limit block endsthe loop, and passes control to a function block 385. The function block385 saves the encoded picture in decoded pictures buffer (dqb), andpasses control to an end block 390.

Since the cross-view prediction of each slice is fully configurableusing cross-view coding type and view prediction lists, the Multi-viewVideo Coding (MVC) codec can support arbitrary view coding order andview scalability.

In an embodiment, at the MB level, a new syntax called mvc_pred_flagindicates whether temporal prediction or cross-view prediction is usedfor coding each signal block. In the case of mvc_pred_flag=0,List0/List1 will be utilized for motion compensation depending onslice_type. When mvc_pred_flag=1, then ViewList0/ViewList1 will beutilized depending on view_slice_type.

Turning to FIG. 4, an exemplary method for performing a temporal/crossview mode decision is indicated generally by the reference numeral 400.The method 400 includes a start block 405 that passes control to adecision block 410. The decision block 410 determines whether or not thecurrent slice type is P slice or B slice. If so, then control is passedto a function block 415. Otherwise, control is passed to a decisionblock 430.

The function block 415 constructs List0 using temporal references, andpasses control to a decision block 420. The decision block 420determines whether or not the current slice type is B slice. If so, thecontrol is passed to a function block 425. Otherwise, control is passedto the decision block 430.

The function block 425 constructs List1 using temporal references, andpasses control to the decision block 430.

The decision block 430 determines whether or not the current view slicetype is P slice or B slice. If so, then control is passed to a functionblock 435. Otherwise, control is passed to a loop limit block 450.

The function block 435 constructs ViewList0 using cross-view references,and passes control to a decision block 440. The decision block 440determines whether or not the current view slice type is B slice. If so,then control is passed to a function block 445. Otherwise, control ispassed to the loop limit block 450.

The function block 445 constructs the ViewList0 using cross-viewreferences, and passes control to the loop limit block 450.

The loop limit block 450 begins a loop over each macroblock includingsetting a range for the loop using a variable mb=0 toMacroBlocksInPic−1, and passes control to a decision block 455. Thedecision block 455 determines whether or not mvc_prediction_flag isequal to 1. If so, then control is passed to a function block 460.Otherwise, control is passed to a function block 465.

The function block 460 decodes a macroblock using ViewList0/ViewList1,and passes control to a function block 470.

The function block 465 decodes the macroblock using List0/List1, andpasses control to a function block 470.

The function block 470 performs motion/disparity vector bufferprocessing, and passes control to a loop limit block 475. The loop limitblock 475 ends the loop, and passes control to a function block 480. Thefunction block 480 saves the decoded picture in decoded pictures buffer(dqb), and passes control to an end block 485.

Three new CABAC contexts are added for coding the mvc_pred_dir syntax.The context modeling is the same as the transform_size_8×8_flag syntax.

In the multi-view extension of the MPEG-4 AVC standard, the decodedpicture buffer (dpb) needs to be able to handle decoded pictures frommultiple views. Assuming there are N input views, an embodiment of thepresent principles may involve N separate dpb's. Each dpb stores thedecoded pictures from one specific view.

An alternative way of managing dpb is to put all view pictures in asingle dpb. However, the first approach has the following advantages.One advantage of the first approach is that each view has its own dpb,with the same decoded reference marking process as in the MPEG-4 AVCstandard. This simpler approach reduces the complications of managingdifferent view pictures in the same dpb. Another advantage of the firstapproach relates to the undesirability of reducing the number ofavailable temporal reference frames, since temporal correlation isgenerally stronger than cross-view correlation. With each view managingits own reference pictures in its, dpb, the temporal prediction willhave the same multiple reference frame prediction capability as insimulcast.

A distinctive trait of MVC comparing to conventional video coding is theco-existence of both motion and disparity. The blocks that aretemporally predicted will need to signal motion vectors (MV), versusdisparity vectors (DV) for cross-view prediction.

Two exemplary methods are described herein for dealing with both motionvectors and disparity vectors for the same slice. However, it is to beappreciated that given the teachings of the present invention providedherein, one of ordinary skill in this and related arts will contemplatethese and other methods for the same, while maintaining the scope of thepresent invention.

In the first method, for each block, signal and store either a motionsvector or a disparity vector but not both. Whether a motion vector or adisparity vector will be signaled and stored depends on the syntaxmvc_pred_flag. This will require less memory storage, but the combinedvector field will not be consistent.

In the second method, for each block, store both a motion vector and adisparity vector. This can be achieved by either signaling both vectors,or only signal one and fill the other one using vector fieldinterpolation. This approach will take more memory storage, but theconsistency of both motion and disparity fields can be better preserved.

An exemplary embodiment of the first method is shown and described withrespect to FIG. 5. An exemplary embodiment of the second method is shownand described with respect to FIG. 6.

Turning to FIG. 5, an exemplary method for processing motion anddisparity vectors for the same slice corresponding to multi-view videocontent is indicated generally by the reference numeral 500. The method500 includes a start block 505 that passes control to a decision block510. The decision block 510 determines whether or not the mvc_pred_flagis equal to 0. If so, then control is passed to a function block 515.Otherwise, control is passed to a function block 520. The function block515 forms the disparity vector predictor, processes the disparity vectorDV, stores the disparity vector DV in VectorBuffer, and passes controlto an end block 525.

The function block 520 forms the motion vector predictor, processes themotion vector MV, stores the motion vector MV in VectorBuffer, andpasses control to the end block 525.

Turning to FIG. 6, another method for processing motion and disparityvectors for multi-view video content is indicated generally by thereference numeral 600. The method 600 includes a start block 605 thatpasses control to a function block 610. The function block 610 forms thedisparity vector predictor, processes the disparity vector DV, storesthe disparity vector DV in VectorBuffer1, and passes control to afunction block 615. The function block 615 forms the motion vectorpredictor, processes the motion vector MV, stores the motion vector MVin VectorBuffer2, and passes control to an end block 620.

The implication of having both motion and disparity vectors in thecoding of the same slice arises in the following aspects: (1) predictivecoding of motion/disparity vectors; and (2) Direct and Skip modes.

In the MPEG-4 AVC standard, motion vector components are differentiallycoded using either median or directional prediction from neighboringblocks. In Multi-view Video Coding, the neighboring blocks might have adifferent prediction direction(s) than the current block. In order tosave bits in the coding of motion/disparity vectors, it is preferable touse the most correlated information to form a predictor. Depending uponwhether there are both motion vectors and disparity vectors availablefor the neighboring blocks, for the first method, use only thoseneighboring blocks that have the same prediction direction; for thesecond method, use only the motion vectors of the neighboring blocks informing the motion vector predictor, and use only the disparity vectorsof the neighboring blocks in forming the disparity predictor.

Aside from spatial neighboring blocks, temporally co-located blocks canalso be used to enhance the disparity prediction because the disparityfields are usually stationary in the temporal dimension.

Skip and Direct modes in the MPEG-4 AVC standard are effective codingtools that better exploit the spatiotemporal correlation that existsbetween adjacent macroblocks, because they can represent motion withouthaving to transmit motion vectors. In Multi-view Video Coding, thosemodes should be adapted in order to, take into account the additionalcross-view correlation.

For P_Skip modes, the reconstructed signal is obtained similar to theprediction signal of a P_16×16 macroblock type that references thepicture which is located at index 0 of List0. The motion vector used forreconstructing the P_Skip macroblock is similar to the motion vectorpredictor for the 16×16 block. In MVC, the above-mentioned adaptation ofthe motion/disparity vector predictor will help to make P_Skip mode moreuseful.

For B_SLICE coding, B_Skip/B_Direct_16×16/B_Direct_8×8 modes should beadapted to consider the mixing of motion and disparity. There are twodifferent Direct modes supported in the MPEG-4 AVC standard, namelytemporal Direct and spatial Direct.

For the temporal Direct mode, motion vectors are derived from theco-located position in the first List1 reference. When the first List1reference is disparity predicted, the system can either look for motionvectors at the lo-located position in other List1 references(ref_idx>0), or use the spatial motion vector predictor.

For the spatial Direct mode, the motion vectors are derived in a similarmanner employed by P_SKIP, but with both List0/List1 considered. Thesame adaptation done in P_SKIP can be extended in List1 also.

Tables 1-4 illustrates various syntaxes for Multi-view Video Codingincluding those in accordance with various embodiments of the presentprinciples. Table 1 illustrates the sequence parameter set RBSP syntaxfor Multi-view Video Coding. Table 2 illustrates the picture parameterset RBSP syntax for Multi-view Video Coding. Table 3 illustrates theslice header syntax for Multi-view Video Coding. Table 4 illustrates themacroblock layer syntax for Multi-view Video Coding.

TABLE 1 seq_parameter_set_rbsp( ) { C Descriptor log2_max_view_num_minus1 0 ue(v)  num_views_sps 0 u(log2_max_view_num_minus1 + 1)  view_id_sps 0 u(log2_max_view_num_minus1 + 1)  profile_idc 0 u(8)  constraint_set0_flag0 u(1)  constraint_set1_flag 0 u(1)  constraint_set2_flag 0 u(1) constraint_set3_flag 0 u(1)  reserved_zero_4bits /* equal to 0 */ 0u(4)  ...

TABLE 2 pic_parameter_set_rbsp( ) { C Descriptor  view_id_pps 0 u(log2_max_view_num_minus1 + 1)  pic_parameter_set_id 1 ue(v) seq_parameter_set_id 1 ue(v)  entropy_coding_mode_flag 1 u(1) pic_order_present_flag 1 u(1)  num_slice_groups_minus1 1 ue(v)  ...

TABLE 3 slice_header( ) { C Descriptor  first_mb_in_slice 2 ue(v) view_id 2 u (log2_max_view_num_minus1 + 1)  view_slice_type 2 ue(v)  if(view_slice_type == VL_SLICE) {   num_ref_idx_ll_active_minus1 2 ue(v)  for (i=0; i<= num_ref_idx_ll_active_minus1; i++) {   left_ref_view_id[i] 2 ue(v)   }  }  if (view_slice_type == VR_SLICE){   num_ref_idx_lr_active_minus1 2 ue(v)   for(i=0; i<=num_ref_idx_lr_active_minus1; i++) {    right_ref_view_id[i] 2 ue(v)   } }  if(view_slice_type == VB_SLICE) {   num_ref_idx_ll_active_minus1 2ue(v)   for (i=0; i<= num_ref_idx_ll_active_minus1; i++) {   left_ref_view_id[i] 2 ue(v)   }   num_ref_idx_lr_active_minus1 2ue(v)   for (i=0; i<= num_ref_idx_lr_active_minus1; i++) {   right_ref_view_id[i] 2 ue(v)   }  }  ...  slice_type 2 ue(v) pic_parameter_set_id 2 ue(v)  frame_num 2 u(v)  ...

TABLE 4 macroblock_layer( ) { C Descriptor  nivc_pred_flag 2 u(1)|ae(v) mb_type 2 ue(v)|ae(v)  if( mb_type = = 1_PCM ) {   while(!byte_aligned( ) )    pem_alignment_zero_bit 2 f(1)   for( i = 0; i <256; i++ )    pem_sample_luma[ i ] 2 u(v)  ...

A description will now, be given of some of the many attendantadvantages/features of the present invention, some of which have beenmentioned above. For example, one advantage/feature is a video encoderthat includes an encoder for encoding a block in a picture using atleast one of two cross-view reference picture lists. The picture is oneof a set of pictures corresponding to multi-view video content andhaving different view points with respect to a same or similar scene.The picture represents a current one of the different view points. Thetwo cross-view reference picture lists correspond to reference pictureshaving ones of the different views points other than the current one.

Another advantage/feature is the video encoder as described above,wherein the two cross-view reference picture lists are different thanList0 and List 1 of the International Organization forStandardization/International Electrotechnical Commission Moving PictureExperts Group-4 Part 0.10 Advanced Video Coding standard/InternationalTelecommunication Union, Telecommunication Sector H.264 recommendation.

Yet another advantage/feature is a video encoder that includes at leastone buffer for storing decoded pictures corresponding to multi-viewcontent for different view points of a same or similar scene.

Moreover, another advantage/feature is the video encoder as describedabove, wherein the at least one buffer includes a separate buffer, foreach of the different view points.

These and other features and advantages of the present invention may bereadily ascertained by one of ordinary skill in the pertinent art basedon the teachings herein. It is to be understood that the teachings ofthe present invention may be implemented in various forms of hardware,software, firmware, special purpose processors, or combinations thereof.

Most preferably, the teachings of the present invention are implementedas a combination of hardware and software. Moreover, the software may beimplemented as an application program tangibly embodied on a programstorage unit. The application program may be uploaded to, and executedby, a machine comprising any suitable architecture. Preferably, themachine is implemented on a computer platform having hardware such asone or more central processing units (“CPU”), a random access memory(“RAM”), and input/output (“I/O”) interfaces. The computer platform mayalso include an operating system and microinstruction code. The variousprocesses and functions described herein may be either part of themicroinstruction code or part of the application program, or anycombination thereof, which may be executed by a CPU. In addition,various other peripheral units may be connected to the computer platformsuch as an additional data storage unit and a printing unit.

It is to be further understood that, because some of the constituentsystem components and methods depicted in the accompanying drawings arepreferably implemented in software, the actual connections between thesystem components or the process function blocks may differ dependingupon the manner in which the present invention is programmed. Given theteachings herein, one of ordinary skill in the pertinent art will beable to contemplate these and similar implementations or configurationsof the present invention.

Although the illustrative embodiments have been described herein withreference to the accompanying drawings, it is to be understood that thepresent invention is not limited to those precise embodiments, and thatvarious changes and modifications may be effected therein by one ofordinary skill in the pertinent art without departing from the scope orspirit of the present invention. All such changes and modifications areintended to be included within the scope of the present invention as setforth in the appended claims.

1. A video encoding method, comprising: encoding a block in a picture,the picture being one of a set of pictures corresponding to multi-viewvideo content and having different view points with respect to a same orsimilar scene, the picture representing a current one of the differentview points, characterized by using at least one of two cross-viewreference picture lists for encoding the block, the two cross-viewreference picture lists corresponding to reference pictures having atleast one of the different view points other than the current one (365),wherein the number of cross-view reference pictures and view identifierscorresponding to the crossview reference pictures are indicated in thebitstream for each of the two reference picture lists, and wherein thenumber of cross-view reference pictures and the view identifierscorresponding to the cross-view reference pictures are indicated in aslice header, and wherein said encoding includes at least one buffer forstoring reconstructed pictures corresponding to multi-view content fordifferent view points of a same or similar scene.
 2. A video decodingmethod, comprising: decoding (435, 445) a block in a picture, thepicture being one of a set of pictures corresponding to multi-view videocontent and having different view points with respect to a same orsimilar scene, the picture representing a current one of the differentview points, characterized by using at least one of two cross-viewreference picture lists, for decoding the block, the two cross-viewreference picture lists corresponding to reference pictures having atleast one of the different view points other than the current one,wherein the number of cross-view reference pictures and view identifierscorresponding to the cross-view reference pictures are indicated in thebitstream for each of the two reference picture lists, and wherein thenumber of cross-view reference pictures and the view identifierscorresponding to the cross-view reference pictures are indicated in aslice header, and wherein said encoding includes at least one buffer forstoring reconstructed pictures corresponding to multi-view content fordifferent view points of a same or similar scene.
 3. A video encoder,comprising: an encoder (100) for encoding a block in a picture, thepicture being one of a set of pictures corresponding to multi-view videocontent and having different view points with respect to a same orsimilar scene, the picture representing a current one of the differentview points, characterized in that the encoder uses at least one of tworeference picture lists for encoding the block, the two referencepicture lists corresponding to reference pictures having at least one ofthe different view points other than the current one, wherein the numberof cross-view reference pictures and view identifiers corresponding tothe cross-view reference pictures are indicated in the bitstream foreach of the two reference picture lists, and wherein the number ofcross-view reference pictures and the view identifiers corresponding tothe cross-view reference pictures are indicated in a slice header, andwherein said encoding includes at least one buffer for storingreconstructed pictures corresponding to multi-view content for differentview points of a same or similar scene.
 4. A video decoder, comprising:a decoder (200) for decoding a block in a picture, the picture being oneof a set of pictures corresponding to multi-view video content andhaving different view points with respect to a same or similar scene,the picture representing a current one of the different view points,characterized in that the decoder uses at least one of two referencepicture lists for decoding the block, the two reference picture listscorresponding to reference pictures having at least one of the differentview points other than the current one, wherein the number of cross-viewreference pictures and view identifiers corresponding to the cross-viewreference pictures are indicated in the bitstream for each of the tworeference picture lists, and wherein the number of cross-view referencepictures and the view identifiers corresponding to the cross-viewreference pictures are indicated in a slice header, and wherein saidencoding includes at least one buffer for storing reconstructed picturescorresponding to multi-view content for different view points of a sameor similar scene.
 5. A storage media having video signal data encodedthereupon, comprising: a block in a picture encoded, the picture beingone of a set of pictures corresponding to multi-view video content andhaving different view points with respect to a same or similar scene,the picture representing a current one of the different view points,characterized in that the block is encoded using at least one of tworeference picture lists, the two reference picture lists correspondingto reference pictures having at least one of the different view pointsother than the current one, wherein the number of cross-view referencepictures and view identifiers corresponding to the cross-view referencepictures are indicated in the bitstream for each of the two referencepicture lists, and wherein the number of cross-view reference picturesand the view identifiers corresponding to the cross-view referencepictures are indicated in a slice header, and wherein said encodingincludes at least one buffer for storing reconstructed picturescorresponding to multi-view content for different view points of a sameor similar scene.